<!DOCTYPE html>
<html lang="en-us">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    
<meta charset="UTF-8">
<title>Preloading Fielddata | Elasticsearch: The Definitive Guide [2.x] | Elastic</title>
<link rel="home" href="index.html" title="Elasticsearch: The Definitive Guide [2.x]">
<link rel="up" href="docvalues-and-fielddata.html" title="Doc Values and Fielddata">
<link rel="prev" href="_fielddata_filtering.html" title="Fielddata Filtering">
<link rel="next" href="_preventing_combinatorial_explosions.html" title="Preventing Combinatorial Explosions">
<meta name="DC.type" content="Learn/Docs/Legacy/Elasticsearch/Definitive Guide/2.x">
<meta name="DC.subject" content="Elasticsearch">
<meta name="DC.identifier" content="2.x">
<meta name="robots" content="noindex,nofollow">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="https://cdn.optimizely.com/js/18132920325.js"></script>
    <link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
    <link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
    <link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
    <link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
    <link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
    <link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
    <link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
    <link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
    <link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
    <link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32">
    <link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192">
    <link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96">
    <link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16">
    <link rel="manifest" href="/manifest.json">
    <meta name="apple-mobile-web-app-title" content="Elastic">
    <meta name="application-name" content="Elastic">
    <meta name="msapplication-TileColor" content="#ffffff">
    <meta name="msapplication-TileImage" content="/mstile-144x144.png">
    <meta name="theme-color" content="#ffffff">
    <meta name="naver-site-verification" content="936882c1853b701b3cef3721758d80535413dbfd">
    <meta name="yandex-verification" content="d8a47e95d0972434">
    <meta name="localized" content="true">
    <meta name="st:robots" content="follow,index">
    <meta property="og:image" content="https://www.elastic.co/static/images/elastic-logo-200.png">
    <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
    <link rel="icon" href="/favicon.ico" type="image/x-icon">
    <link rel="apple-touch-icon-precomposed" sizes="64x64" href="/favicon_64x64_16bit.png">
    <link rel="apple-touch-icon-precomposed" sizes="32x32" href="/favicon_32x32.png">
    <link rel="apple-touch-icon-precomposed" sizes="16x16" href="/favicon_16x16.png">
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
    <link rel="stylesheet" type="text/css" href="/guide/static/styles.css">
  </head>

  <!--© 2015-2021 Elasticsearch B.V. Copying, publishing and/or distributing without written permission is strictly prohibited.-->

  <body>
    <!-- Google Tag Manager -->
    <script>dataLayer = [];</script><noscript><iframe src="//www.googletagmanager.com/ns.html?id=GTM-58RLH5" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
    <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= '//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-58RLH5');</script>
    <!-- End Google Tag Manager -->

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-12395217-16"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'UA-12395217-16');
    </script>

    <!--BEGIN QUALTRICS WEBSITE FEEDBACK SNIPPET-->
    <script type="text/javascript">
      (function(){var g=function(e,h,f,g){
      this.get=function(a){for(var a=a+"=",c=document.cookie.split(";"),b=0,e=c.length;b<e;b++){for(var d=c[b];" "==d.charAt(0);)d=d.substring(1,d.length);if(0==d.indexOf(a))return d.substring(a.length,d.length)}return null};
      this.set=function(a,c){var b="",b=new Date;b.setTime(b.getTime()+6048E5);b="; expires="+b.toGMTString();document.cookie=a+"="+c+b+"; path=/; "};
      this.check=function(){var a=this.get(f);if(a)a=a.split(":");else if(100!=e)"v"==h&&(e=Math.random()>=e/100?0:100),a=[h,e,0],this.set(f,a.join(":"));else return!0;var c=a[1];if(100==c)return!0;switch(a[0]){case "v":return!1;case "r":return c=a[2]%Math.floor(100/c),a[2]++,this.set(f,a.join(":")),!c}return!0};
      this.go=function(){if(this.check()){var a=document.createElement("script");a.type="text/javascript";a.src=g;document.body&&document.body.appendChild(a)}};
      this.start=function(){var a=this;window.addEventListener?window.addEventListener("load",function(){a.go()},!1):window.attachEvent&&window.attachEvent("onload",function(){a.go()})}};
      try{(new g(100,"r","QSI_S_ZN_emkP0oSe9Qrn7kF","https://znemkp0ose9qrn7kf-elastic.siteintercept.qualtrics.com/WRSiteInterceptEngine/?Q_ZID=ZN_emkP0oSe9Qrn7kF")).start()}catch(i){}})();
    </script><div id="ZN_emkP0oSe9Qrn7kF"><!--DO NOT REMOVE-CONTENTS PLACED HERE--></div>
    <!--END WEBSITE FEEDBACK SNIPPET-->

    <div id="elastic-nav" style="display:none;"></div>
    <script src="https://www.elastic.co/elastic-nav.js"></script>

    <!-- Subnav -->
    <div>
      <div>
        <div class="tertiary-nav d-none d-md-block">
          <div class="container">
            <div class="p-t-b-15 d-flex justify-content-between nav-container">
              <div class="breadcrum-wrapper"><span><a href="/guide/" style="font-size: 14px; font-weight: 600; color: #000;">Docs</a></span></div>
            </div>
          </div>
        </div>
      </div>
    </div>

    <div class="main-container">
      <section id="content">
        <div class="content-wrapper">

          <section id="guide" lang="en">
            <div class="container">
              <div class="row">
                <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                  <!-- start body -->
                  <div class="page_header">
<p>
  <strong>WARNING</strong>: The 2.x versions of Elasticsearch have passed their
  <a href="https://www.elastic.co/support/eol">EOL dates</a>. If you are running
  a 2.x version, we strongly advise you to upgrade.
</p>
<p>
  This documentation is no longer maintained and may be removed. For the latest
  information, see the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html">current
  Elasticsearch documentation</a>.
</p>
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch: The Definitive Guide [2.x]</a></span>
»
<span class="breadcrumb-link"><a href="aggregations.html">Aggregations</a></span>
»
<span class="breadcrumb-link"><a href="docvalues-and-fielddata.html">Doc Values and Fielddata</a></span>
»
<span class="breadcrumb-node">Preloading Fielddata</span>
</div>
<div class="navheader">
<span class="prev">
<a href="_fielddata_filtering.html">« Fielddata Filtering</a>
</span>
<span class="next">
<a href="_preventing_combinatorial_explosions.html">Preventing Combinatorial Explosions »</a>
</span>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="preload-fielddata"></a>Preloading Fielddata<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch-definitive-guide/edit/2.x/300_Aggregations/115_eager.asciidoc">edit</a>
</h2>
</div></div></div>
<p>The default behavior of Elasticsearch is to load in-memory fielddata <em>lazily</em>.
The first time Elasticsearch encounters a query that needs fielddata for a
particular field, it will load that entire field into memory for each segment
in the index.</p>
<p>For small segments, this requires a negligible amount of time.  But if you
have a few 5 GB segments and need to load 10 GB of fielddata into memory, this
process could take tens of seconds.  Users accustomed to subsecond response
times would all of a sudden be hit by an apparently unresponsive website.</p>
<p>There are three methods to combat this latency spike:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Eagerly load fielddata
</li>
<li class="listitem">
Eagerly load global ordinals
</li>
<li class="listitem">
Prepopulate caches with warmers
</li>
</ul>
</div>
<p>All are variations on the same concept: preload the fielddata so that there is
no latency spike when the user needs to execute a search.</p>
<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="eager-fielddata"></a>Eagerly Loading Fielddata<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch-definitive-guide/edit/2.x/300_Aggregations/115_eager.asciidoc">edit</a>
</h3>
</div></div></div>
<p>The first tool is called <em>eager loading</em> (as opposed to the default lazy
loading). As new segments are created (by refreshing, flushing, or merging),
fields with eager loading enabled will have their per-segment fielddata
preloaded <em>before</em> the segment becomes visible to search.</p>
<p>This means that the first query to hit the segment will not need to trigger
fielddata loading, as the in-memory cache has already been populated. This
prevents your users from experiencing the <em>cold cache</em> latency spike.</p>
<p>Eager loading is enabled on a per-field basis, so you can control which fields
are pre-loaded:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT /music/_mapping/_song
{
  "tags": {
    "type": "string",
    "fielddata": {
      "loading" : "eager" <a id="CO222-1"></a><i class="conum" data-value="1"></i>
    }
  }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO222-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>By setting <code class="literal">fielddata.loading: eager</code>, we tell Elasticsearch to preload
this field’s contents into memory.</p>
</td>
</tr>
</table>
</div>
<p>Fielddata loading can be set to <code class="literal">lazy</code> or <code class="literal">eager</code> on existing fields, using
the <code class="literal">update-mapping</code> API.</p>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>Eager loading simply shifts the cost of loading fielddata.  Instead of paying
at query time, you pay at refresh time.</p>
<p>Large segments will take longer to refresh than small segments.  Usually,
large segments are created by merging smaller segments that are already
visible to search, so the slower refresh time is not important.</p>
</div>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="global-ordinals"></a>Global Ordinals<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch-definitive-guide/edit/2.x/300_Aggregations/115_eager.asciidoc">edit</a>
</h3>
</div></div></div>
<p>One of the techniques used to reduce the memory usage of string
fielddata is called <em>ordinals</em>.</p>
<p>Imagine that we have a billion documents, each of which has a <code class="literal">status</code> field.
There are only three statuses: <code class="literal">status_pending</code>, <code class="literal">status_published</code>,
<code class="literal">status_deleted</code>. If we were to hold the full string status in memory for
every document, we would use 14 to 16 bytes per document, or about 15 GB.</p>
<p>Instead, we can identify the three unique strings, sort them, and number them: 0, 1, 2.</p>
<pre class="literallayout">Ordinal | Term
-------------------
0       | status_deleted
1       | status_pending
2       | status_published</pre>

<p>The original strings are stored only once in the ordinals list, and each
document just uses the numbered ordinal to point to the value that it
contains.</p>
<pre class="literallayout">Doc     | Ordinal
-------------------------
0       | 1  # pending
1       | 1  # pending
2       | 2  # published
3       | 0  # deleted</pre>

<p>This reduces memory usage from 15 GB to less than 1 GB!</p>
<p>But there is a problem. Remember that fielddata caches are <em>per segment</em>.  If
one segment contains only two statuses—<code class="literal">status_deleted</code> and
<code class="literal">status_published</code>—then the resulting ordinals (0 and 1) will not be the
same as the ordinals for a segment that contains all three statuses.</p>
<p>If we try to run a <code class="literal">terms</code> aggregation on the <code class="literal">status</code> field, we need to
aggregate on the actual string values, which means that we need to identify
the same values across all segments.  A naive way of doing this would be to
run the aggregation on each segment, return the string values from each
segment, and then reduce them into an overall result.  While this would work,
it would be slow and CPU intensive.</p>
<p>Instead, we use a structure called <em>global ordinals</em>.  Global ordinals are a
small in-memory data structure built on top of fielddata.  Unique values are
identified <em>across all segments</em> and stored in an ordinals list like the one
we have already described.</p>
<p>Now, our <code class="literal">terms</code> aggregation can just aggregate on the global ordinals, and
the conversion from ordinal to actual string value happens only once at the
end of the aggregation. This increases performance of aggregations (and
sorting) by a factor of three or four.</p>
<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="_building_global_ordinals"></a>Building global ordinals<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch-definitive-guide/edit/2.x/300_Aggregations/115_eager.asciidoc">edit</a>
</h4>
</div></div></div>
<p>Of course, nothing in life is free.  Global ordinals cross all segments in an
index, so if a new segment is added or an old segment is deleted, the global
ordinals need to be rebuilt.  Rebuilding requires reading every unique term in
every segment.  The higher the cardinality—​the more unique terms that exist—​the longer this process takes.</p>
<p>Global ordinals are built on top of in-memory fielddata and doc values.  In
fact, they are one of the major reasons that doc values perform as well as
they do.</p>
<p>Like fielddata loading, global ordinals are built lazily, by default.  The
first request that requires fielddata to hit an index will trigger the
building of global ordinals. Depending on the cardinality of the field, this
can result in a significant latency spike for your users.  Once global
ordinals have been rebuilt, they will be reused until the segments in the index
change: after a refresh, a flush, or a merge.</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h4 class="title">
<a id="eager-global-ordinals"></a>Eager global ordinals<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch-definitive-guide/edit/2.x/300_Aggregations/115_eager.asciidoc">edit</a>
</h4>
</div></div></div>
<p>Individual string fields can be configured to prebuild global ordinals eagerly:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT /music/_mapping/_song
{
  "song_title": {
    "type": "string",
    "fielddata": {
      "loading" : "eager_global_ordinals" <a id="CO223-1"></a><i class="conum" data-value="1"></i>
    }
  }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO223-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>Setting <code class="literal">eager_global_ordinals</code> also implies loading fielddata eagerly.</p>
</td>
</tr>
</table>
</div>
<p>Just like the eager preloading of fielddata, eager global ordinals are built
before a new segment becomes visible to search.</p>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>Ordinals are only built and used for strings.  Numerical data (integers, geopoints,
dates, etc) doesn’t need an ordinal mapping, since the value itself acts as an
intrinsic ordinal mapping.</p>
<p>Therefore, you can only enable eager global ordinals for string fields.</p>
</div>
</div>
<p>Doc values can also have their global ordinals built eagerly:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT /music/_mapping/_song
{
  "song_title": {
    "type":       "string",
    "doc_values": true,
    "fielddata": {
      "loading" : "eager_global_ordinals" <a id="CO224-1"></a><i class="conum" data-value="1"></i>
    }
  }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO224-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>In this case, fielddata is not loaded into memory, but doc values are
loaded into the filesystem cache.</p>
</td>
</tr>
</table>
</div>
<p>Unlike fielddata preloading, eager building of global ordinals can have an
impact on the <em>real-time</em> aspect of your data.  For very high cardinality
fields, building global ordinals can delay a refresh by several seconds.  The
choice is between paying the cost on each refresh, or on the first query after
a refresh.  If you index often and query seldom, it is probably better to pay
the price at query time instead of on every refresh.</p>
<div class="tip admon">
<div class="icon"></div>
<div class="admon_content">
<p>Make your global ordinals pay for themselves. If you have very high
cardinality fields that take seconds to rebuild, increase the
<code class="literal">refresh_interval</code> so that global ordinals remain valid for longer.  This will
also reduce CPU usage, as you will need to rebuild global ordinals less often.</p>
</div>
</div>
</div>

</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="index-warmers"></a>Index Warmers<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch-definitive-guide/edit/2.x/300_Aggregations/115_eager.asciidoc">edit</a>
</h3>
</div></div></div>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<h3>Deprecated in 2.3.0.</h3>
<p>Thanks to disk-based norms and doc values, warmers don’t have use-cases anymore.</p>
</div>
</div>
<p>Finally, we come to <em>index warmers</em>.  Warmers predate eager fielddata loading
and eager global ordinals, but they still serve a purpose. An index warmer
allows you to specify a query and aggregations that should be run before a new
segment is made visible to search. The idea is to prepopulate, or <em>warm</em>,
caches so your users never see a spike in latency.</p>
<p>Originally, the most important use for warmers was to make sure that fielddata
was pre-loaded, as this is usually the most costly step.  This is now better
controlled with the techniques we discussed previously.  However, warmers can
be used to prebuild filter caches, and can still be used to preload fielddata
should you so choose.</p>
<p>Let’s register a warmer and then talk about what’s happening:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT /music/_warmer/warmer_1 <a id="CO225-1"></a><i class="conum" data-value="1"></i>
{
  "query" : {
    "bool" : {
      "filter" : {
        "bool": {
          "should": [ <a id="CO225-2"></a><i class="conum" data-value="2"></i>
            { "term": { "tag": "rock"        }},
            { "term": { "tag": "hiphop"      }},
            { "term": { "tag": "electronics" }}
          ]
        }
      }
    }
  },
  "aggs" : {
    "price" : {
      "histogram" : {
        "field" : "price", <a id="CO225-3"></a><i class="conum" data-value="3"></i>
        "interval" : 10
      }
    }
  }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO225-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>Warmers are associated with an index (<code class="literal">music</code>) and are registered using
the <code class="literal">_warmer</code> endpoint and a unique ID (<code class="literal">warmer_1</code>).</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO225-2"><i class="conum" data-value="2"></i></a></p>
</td>
<td align="left" valign="top">
<p>The three most popular music genres are pre-warmed to help encourage caching.</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO225-3"><i class="conum" data-value="3"></i></a></p>
</td>
<td align="left" valign="top">
<p>The fielddata and global ordinals for the <code class="literal">price</code> field will be preloaded.</p>
</td>
</tr>
</table>
</div>
<p>Warmers are registered against a specific index.  Each warmer is given a
unique ID, because you can have multiple warmers per index.</p>
<p>Then you just specify a query, any query.  It can include queries, filters,
aggregations, sort values, scripts—​literally any valid query DSL.  The
point is to register queries that are representative of the traffic that your
users will generate, so that appropriate caches can be prepopulated.</p>
<p>When a new segment is created, Elasticsearch will <em>literally</em> execute the queries
registered in your warmers.  The act of executing these queries will force
caches to be loaded.  Only after all warmers have been executed will the segment
be made visible to search.</p>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>Similar to eager loading, warmers shift the cost of cold caches to refresh time.
When registering warmers, it is important to be judicious.  You <em>could</em> add
thousands of warmers to make sure every cache is populated—​but that will
drastically increase the time it takes for new segments to be made searchable.</p>
<p>In practice, select a handful of queries that represent the majority of your
user’s queries and register those.</p>
</div>
</div>
<p>Some administrative details (such as getting existing warmers and deleting warmers) that have been omitted from this explanation.  Refer to the <a href="/guide/en/elasticsearch/reference/2.4/indices-warmers.html" class="ulink" target="_top">warmers documentation</a> for the rest
of the details.</p>
</div>

</div>
<div class="navfooter">
<span class="prev">
<a href="_fielddata_filtering.html">« Fielddata Filtering</a>
</span>
<span class="next">
<a href="_preventing_combinatorial_explosions.html">Preventing Combinatorial Explosions »</a>
</span>
</div>
</div>

                  <!-- end body -->
                </div>
                <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                  <div id="rtpcontainer" style="display: block;">
                    <div class="mktg-promo">
                      <h3>Most Popular</h3>
                      <ul class="icons">
                        <li class="icon-elasticsearch-white"><a href="https://www.elastic.co/webinars/getting-started-elasticsearch?baymax=default&amp;elektra=docs&amp;storm=top-video">Get Started with Elasticsearch: Video</a></li>
                        <li class="icon-kibana-white"><a href="https://www.elastic.co/webinars/getting-started-kibana?baymax=default&amp;elektra=docs&amp;storm=top-video">Intro to Kibana: Video</a></li>
                        <li class="icon-logstash-white"><a href="https://www.elastic.co/webinars/introduction-elk-stack?baymax=default&amp;elektra=docs&amp;storm=top-video">ELK for Logs &amp; Metrics: Video</a></li>
                      </ul>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </section>

        </div>


<div id="elastic-footer"></div>
<script src="https://www.elastic.co/elastic-footer.js"></script>
<!-- Footer Section end-->

      </section>
    </div>

<script src="/guide/static/jquery.js"></script>
<script type="text/javascript" src="/guide/static/docs.js"></script>
<script type="text/javascript">
  window.initial_state = {}</script>
  </body>
</html>
